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(57) Abstract 

An Application Programming 
Interface (API) for applications to 
manage/access user-related information 
on a Digital Television (DTV) 
Receiver/Terminal. The API provides 
a multi-user environment (using user 
registry (210) and user profile (220) 
classes), and a registry for preferences 
(310) which can be associated with 
an individual user (user-specific) or be 
common to all users (system-wide). A 
set of permissions (230) is associated 
with each user, or at least with a default 
user, which represents anybody watching 
the TV. The permission may provide, 
for example, a parental control/rating 
ceiling or permission to buy Impulse 
Pay Per View (IPPV) programs, or 
engage in e-commerce transactions 

(e.g., purchase goods or services via the television). The invention also supports a mechanism (220) where some applications can, and 
some cannot, access the preferences based on a security policy. This means that the user may allow only specified trusted applications to 
access his/her credit card number but not others, for example, for an e-commerce application. 
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DIGITAL TELEVISION RECEIVER WITH APPLICATION PROGRAMMING INTERFACE FOR USER MANAGEMENT 



BACKGROUND OF THE INVENTION 

5 This application claims the benefit of U.S. 

Provisional Application No. 60/107,949, filed November 
12, 1998. 

The present invention provides an Application 
Programming Interface (API) for downloadable broadcast 

10 applications to manage/access user-related information 

on a Digital Television (DTV) Receiver/Terminal. 

A set-top terminal, also referred to as an 
Integrated Receiver-Decoder (IRD) or a subscriber 
terminal, is a device that receives and decodes 

15 television signals for presentation by a television. 

The signals can be delivered over a satellite, through 
a cable plant, or by means of terrestrial broadcast, 
for example. Various applications have been proposed, 
or are currently available, via modern set tops, 

2 0 including video on demand (VOD) , audio on demand, pay- 

per-view, interactive shopping, electronic commerce, 
electronic program guides, Internet browsers, mail 
services (e.g., text e-mail, voice mail, audio mail, 
and/or video mail) , telephony services, stock ticker, 

25 weather data, travel information, games, gambling, 

banking, shopping, voting, and others. Applications 
may also enable Internet connectivity and possibly 
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Internet -based telephony. The set top functionality is 
enabled through specialized hardware and software. 

The applications may be downloaded by terminals 
via a network, loaded locally (e.g., via a smart card), 
or installed at the time of manufacture, for example. 

Moreover, with the increasing integration of 
computer networks such as the Internet, telephony 
networks, and broadband distribution networks, many 
opportunities arise for providing new types of 
applications . 

To optimize the user's ability to access these 
applications, there is a need for user management at 
the terminals. In particular, it would be desirable to 
provide a user -management API that can be implemented 
in software independently of a terminal's hardware and 
operating system. 

The API should allow new users to be recognized, 
or old users to be deleted, as well as recognizing a 
current user of the terminal . The API should provide a 
profile of the each user and maintain a record of 
permissions that have been granted to the users, e.g., 
for accessing applications such as pay-per-view, or 
enforcing rating guidelines for children. 

The API should maintain a record of user 
preferences, such as preferred language and rating 
ceilings, personal data such as age, address, zip code, 
account numbers, as well as system-wide preferences, 
such as favorite channels, language, etc. 

The API should also maintain a registry of 
applications, resources, preferences and users. An 
application may use/access a resource, which is usually 



WO 00/30345 



3 



PCT/US99/23346 



a device, function or a process on the receiver (e.g. 
tuner, modem, database, etc.) 

The API should be compatible with Java(tm), 
ActiveX (tm) or an equivalent type of component based 
5 object-oriented technology. 

The API should be compatible with Digital Audio 
Visual Council (DAVIC) , American Television Standards 
Committee (ATSC) T3/S17 Digital TV Application Software 
Environment (DASE) , Digital Video Broadcast (DVB) - 
10 Multi-Media Home Platform (MHP) and other related 

environments . 

The API should be compatible with any application 
at a terminal, regardless of how the application was 
received or installed (e.g., downloaded, resident, from 
15 smart card, etc.) 

The present invention provides a system having the 
above and other advantages. 
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SUMMARY OF THE INVENTION 
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The present invention provides a software 
architecture a set-top television terminal. In 
particular, an Application Programming Interface (API ) 
is provided for applications to manage/access user- 
related information on the terminal. 

A "user" is one who is watching the TV or using 
its other functions, e.g., E-mail, games, etc. 

The API includes a user software package that 
includes registry, profile, permissions, change cause, 
change event, and registry event functions. A 
preferences package includes a registry, names, rating, 
preferred language, change cause, change event and 
registry event functions. A registry package includes 
15 type, factory, change event, listener, user, 

preference, resource and application functions. 

The present invention provides a mult i -user 
environment (user registry and user profile) , and a 
registry for preferences which can be associated with 
an individual user (user-specific) or be common to all 
users (system-wide) . A set of permissions is 
associated with each user, or at least with a default 
user, which represents anybody watching the TV. 

in a particular embodiment, a television set-top 
terminal includes a computer readable medium having 
computer program code means, and means for executing 
the computer program code means to implement an 
Application Programming Interface (API) . The API 
provides (a) a user registry of a plurality of users of 
the terminal, (b) a preferences registry of preferences 
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of the users, and (c) permission (s) for controlling the 
users' access to at least one application that is 
provided at the terminal . 

The API provides a security policy to allow only 
specified applications to access the preferences 
registry. The security policy may be user-controlled. 
Thus, some applications can, and some cannot, access 
the preferences based on a security policy. This means 
that the user may allow only specified trusted 
applications to access his/her credit card number but 
not others, for example. These applications may be 
specified shop-at-home channels or the like. 

The API disallows access to user preferences by an 
application that does not have the required 
permission (s) . 

The permission (s) may be associated with each user 
individually, or may be associated with a default user. 
A default user might be provided to indicate that the 
entire family is watching the television together, or 
to indicate a guest or unknown person. 

Additionally, the application generally is 
responsive to the user preferences. For example, if an 
application such as an Electronic Program Guide (EPG) 
accesses a language preference of a particular user, 
the application can automatically select the language 
for text when the service information (SI) is 
multilingual. An application that tunes to channels 
(audio/video or audio-only) may automatically select 
the appropriate audio language based on the user's 
language preference. 

As another example, an EPG application may access 
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favorite channel information of a user to prepare a 
custom made guide to the programs that are currently 
playing. Or, an application which enables targeted 
advertisements may access information regarding a 
user's location (ZIP code), gender, age, family status, 
and other personal information, such as pets, hobbies, 
etc . 

Additionally, e-commerce-type applications may 
need to look at user credit card numbers, permissions 
to do on-line purchases, and other related preferences. 

The permission may also provide, for example, a 
parental control /rating ceiling or permission to buy 
Impulse Pay Per View (IPPV) programs, or engage in e- 
commerce transactions (e.g., purchase goods or services 
via the television - home shopping) . 

The preferences include a ratings ceiling 
preference . 

Moreover, the user preferences may include system- 
wide or user-specific. 

The user registry can be used to register a new 
user of the terminal, identify a current user of the 
terminal, and remove a former user of the terminal. 

For example, when an application needs to switch 
between users, it may do it by identifying the user 
using a logon screen, by PIN codes or passwords, or 
even personalized smart cards, or voice control, for 
example . 

The permission (s) enable the users to access a 
resource/ invoke functions of the terminal. This refers 
to accessing either some physical resource on the 
receiver, such as a modem or a tuner, the smart card, 
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etc., or an application, such as e-mail, web browsing, 
e- commerce, etc. 

The resource may be, for example, a device, 
function or a process on the receiver, such as a tuner, 
modem, database, plug- in module, cable, software 
module, network interface card, persistent storage, TV 
screen space, memory, CPU, conditional access (CA) 
module, and so forth. 

The API also is adapted to define one or more new 
types of user preferences, and add the new types of 
user preferences to the preferences registry. The new 
user preferences can be defined by a base interface, 
Preference, which is an object that can be added or 
removed from the Pref erenceRegistry . This allows one 
to define new types of user preferences, e.g., by 
extending it the same way as the LanguagePref erence 
extends the base Preference. 

For example, the preferences may include specific 
types of programs (sports, drama, humor, action, etc.). 

The API also is adapted to associate the new types 
of user preferences with the users. 

The API may be independent of an operating system 
and hardware of the terminal . 

A corresponding method is also presented. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows package relationships and 
dependencies in accordance with the present invention. 

FIG. 2 illustrates a user class/interface diagram 
in accordance with the present invention. 

FIG. 3 illustrates a preferences class/ interface 
diagram in accordance with the present invention. 

FIG. 4 illustrates a registry class/ interface 
diagram in accordance with the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 
1 . INTRODUCTION 

The present invention provides an Application 
Programming Interface (API) for downloadable broadcast 
applications to manage/access user-related information 
on a Digital Television (DTV) Receiver. 

The invention comprises the following two API 
components: 1) User API; and 2) User Preferences API. 

They can be used together where each user has a 
set of user preferences associated with it, or 
separately where there is a system- level set of 
preferences without a user association. 

A Registry package is also described herein, which 
provides a generic mechanism for registry- type 
constructs . 

2. MODEL DESCRIPTION 

FIG. 1 illustrates an API package in accordance 
with the present invention, namely a User package 110, 
a Preferences package 120, and a Registry package 130. 
These packages are described in the following sections, 
in connection with FIGs 2-4. 

Note that portions of the disclosure were 
generated automatically from Rational Rose(tm) CASE 
tool, developed by Rational Software Corporation, USA. 
The figures use the Rational Rose (tm) depiction of the 
Unified Modeling Language (UML) , which is a language 
for specifying, constructing, visualizing, and 
documenting the artifacts of a software- intensive 
system. A class diagram represents the static 
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structure of a system, and shows a pattern of behaviors 
that the system exhibits. This is accomplished by 
showing the existence of classes and their 
relationships. Each class is represented by a box with 
three sections. The top section lists the class name. 
The middle section denotes a list of attributes, and 
the bottom section denotes a list of operations. 

A solid or dashed line between classes denotes an 
association or dependency. A white diamond tip denotes 
aggregation by reference, while a black diamond tip 
denotes aggregation by value. A triangular arrowhead 
denotes a restricted navigation, e.g., inheritance of 
operation but not of structure. 

Moreover, interfaces and classes begin with an 
uppercase letter, while methods begin with a lowercase 
letter. A class is a template that defines a data 
structure, method and function calls for an object. An 
interface defines a set of methods/f unction calls that 
can be manipulated by a class. The class provides the 
code for implementing an interface. 

2.1 User Package 

FIG. 2 illustrates a user class/interface diagram 
in accordance with the present invention. A main 
UserRegistry interface 210 is the access point for 
getting information about any user. One or more users 
can be associated with each terminal (e.g., DTV 
receiver, set-top box, IRD, TV-enabled PC, etc.) 
Existing users can be retrieved, new ones can be 
created, and the current active user can be set via the 
UserRegistry object 210. The user is represented by the 
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UserProfile object 22 0, which holds the user's name and 
the user's preferences. The preferences may be that 
the user prefers to view/use certain types of 
television programs (e.g., favorite channels) and/or 
applications, preferred audio language, personal data, 
such age, location (address/zip code) , credit card 
numbers, etc. The user can be authenticated by 
invoking the implementation-neutral method 
authenticate () , which may invoke the particular 
mechanism of authenticating a user, such as Personal 

Identification Number (PIN) codes, passwords, etc. 

Users are associated with permissions which are 

internally used to enforce a security policy. 

Therefore, new permissions can be granted to each user. 

The permissions are implementation-specific since they 

are internal to the terminal . 

2.2 Preferences Package 

FIG. 3 illustrates a preferences class/interface 
diagram in accordance with the present invention. 

The preference package 12 0 serves two primary 
purposes: to hold system-wide preferences and to hold 
user-specific preferences. 

A system-wide preference is anything that applies 
to all users. For example, English may be a system 
wide preferred language which applies to all user 
unless they override it with their own user-specific 
preference (e.g. , Spanish) . 

When the preference is used in the system-wide 
sense, the access to it is provided via the 
Pref erenceRegistry 310 obtained from the 
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Registry-Factory 430 (FIG. 4) . The user-specific 
preferences can be obtained directly from the user 
(UserProfile 220) . 

Any new preferences or settings must derive from 
the abstract Preference interface 33 0, which provides 
the listener mechanism and access to the unique 
preference name. The derived class/interface can 
provide any methods, behavior and data structures 
needed to describe the specific preference or settings 
object . 

Each application can register as a listener (using 
the addPropertyChangeListener ( ) method) to a specific 
preference and be notified via the propertyChange ( ) 
method it must implement. 

Properties are uniquely identified by their names. 
If an application tries to store a Property with a 
duplicate name, the Pref erenceAlreadyExist s Exception 
390 will be thrown. If the application does not have 
enough privileges to perform any of the 
Pref erenceRegistry 310 methods, the 
AccessDeniedException 3 85 will be thrown. 

PropertyChangeEvent 350 is defined in the standard 
Java packages (JDK 1.2). Also, the notations "from 
security" in class 385, and "from beans" refer to 
classes ("Security" and "Beans", respectively) that are 
defined in JDK 1.2. 

2.3 Registry Package 

FIG. 4 illustrates a registry class/interface 
diagram in accordance with the present invention. 
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The Registry package 13 0 provides a basic 
mechanism to construct a Registry object of any kind. 
The Registry interface 410 is a base interface which is 
extended by all specific Registries, such as the 
5 UserRegistry 210 or the Pref erenceRegistry 310. 

A RegistryListener interface 440 and a 
RegistryChangeEvent interface 250 are associated with 
this package. The listener interface 440 is used by 
any object that wants to be notified of any changes in 
10 the Registry 410. Changes are considered those that 

affect the Registry 410 itself (not necessarily the 
individual elements in the registry) , such as adding or 
removing elements to/ from the Registry. The 
RegistryChangeEvent 250 is an abstract class which is 
15 extended by the specific registry events. 

Since most of the API is defined in terms of Java 
Interfaces, the RegistryFactory 430 is a class that 
hides the actual object construction implementation. 

The notation "from util" in the EventObject class 
20 415 refers to a class "Util" that is defined in JDK 

1.2. 

The notation "from resource" in the 
ResourceRegistry interface 480 refers to a class 
"Resource" that is discussed in commonly-assigned PCT 

25 Patent Application No. , filed October 7 , 

1999, and entitled "Application Programming Interface 
(API) For Accessing And Managing Resources In A Digital 
Television Receiver." 

The notation "from application" in the 

30 ApplicationRegistry interface 490 refers to a class 

"Application" that is discussed in commonly-assigned 
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PCT Patent Application No. , filed October 

7, 1999, and entitled "Software Application Lifecycle 
And Management For Broadcast Applications." 

3- CLASS AND INTERFACE DESCRIPTION 

The following sections provide the details of each 
class, interface and its methods. 

3 . 1 User Package 

This package 110 provides classes and interfaces 
necessary for user management functions. 

3.1.1 UserRegistry 

UserRegistry interface 210 provides access to all 
users defined on the system. It is derived from 
Registry 130. 

Public Operations: 

createUser (name : String) : UserProfile 

This method will create a new user of the 
specified name. 

Public operations are those methods that may be 
called and used by other objects since they are visible 
outside of the object (e.g., class). In contrast, 
private operations are visible only to the class 
itself. 

getCurrentUser () : UserProfile 

This method returns the user who is currently 
registered as the active user. 

getUser Names () : String [] 

This method returns a list of all known users in 
the registry. 
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setCurrentUser (newUser : String) : UserProfile 

This method defines a new current user. The 
implementation may prompt the user for a password or 
some other method of authentication. 

getUser (name : String) : UserProfile 

This method returns a UserProfile object of the 
specified name. 

3.1.2 UserProfile 

This interface 220 represents a container of a 
single user information, such as settings and 
preferences, billing info, etc. it is derived from 
UserPermissions 230 . 

Public Operations: 

getName () : String 

Returns the name of this user. 
getPreferences () : Pref erenceRegistry 

This method returns this user's 
Pref erenceRegistry . All operations performed on the 
returned list of preferences will be reflected in this 

UserProfile . 

authenticate () : boolean 

This method is called to authenticate a user. It 
invokes an implementation- specif ic mechanism for user 
authentication. It may use a user dialog to ask for a 
password or PIN, or other authentication mechanisms. 

Returns TRUE if authentication succeeded; FALSE 
otherwise . 

grantPennission (newPermission : String) : void 

This method is called to add a new permission to 
, the user. See UserPermissions. 
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3,1*3 UserPermissions 

This interface 230 defines a list of user 
permissions that can be granted to a user. 
Public Attributes: 
5 IPPV : String = "IPPV Purchase" 

RATING : String = "Rating Override" 

3.1.4 UserRegistryEvent 2 60 

Derived from RegistryChangeEvent 250. 
Public Operations : 
10 getUserName () : java.lang. String 

This method returns the User Name of the User that 
caused this event. 

3.1.5 UserChangeCause 

This interface 240 defines possible causes for the 
15 UserRegistryEvent 260. 

Public Attributes: 
USER_ADDED : short = 1 
USERJREMOVED : short = 2 
NEW_CURRENT_USER : short = 3 

20 3.2 Preferences Package 

This package 120 defines a set of interfaces and 
classes which provide a mechanism to define a set of 
preferences, either at the system level or at the user 
level . 
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This exception 390 signals that a preference of 
the same name is already present in the registry and 
cannot be inserted (added) again. It is derived from 
Exception, which is in the JDK 1.2 core Java packages - 
5 j ava . 1 ang . Except ion . 

3.2*2 PreferenceRegistry 

This interface 310 represents a registry of all 
settings and preferences that can be shared by multiple 
applications. It is derived from Registry 13 0. 
10 Public Operations : 

getPref erence (pref erenceName : String) : 
org. atsc .preferences .Preference 

This method returns the preference of the 
specified name, or null if the name is unknown to the 
15 registry. 

addPref erence (aPreference : 
org. atsc .preferences. Pref erence) : void 

This method allows an application to insert a new 
preference object into the registry. The new 
2 0 preference must be of a unique name. 

removePref erence (pref erenceName : String) : void 

This method allows an application to remove a 
preference object from the registry. 
listPref erences () : 
2 5 org. atsc .preferences .Preference [] 

This method returns a list of all Preferences 
currently stored in the registry. 



3.2.3 Pref erredLanguage 
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This interface 340 is an example of a language 
preference interface. An ordered list of ISO 639.2 
alpha- 3 strings is used. The first language in the 
list is the most desirable language. It is derived 
5 from the Preference interface 330. 

Public Operations: 

getLanguage () : String [] 

This method returns an ordered list (most 
desirable first) of three letter ISO language codes. 
10 setLanguage (valueList : String [] ) : void 

This method allows an application to change the 
language preference. It returns the new list. 

3.2.4 RatingPref erence 

This interface 335 represents a parental rating 
15 preference based, e.g., on age. It is derived from the 

Preference interface 330. 
Publ ic Operat ions : 
getRatingCeiling () : String 

This method returns the maximum rating value 
2 0 allowed for watching. 

setRatingCeiling (aValue : String) : String 

This method allows an application to change the 
rating ceiling. It returns the new rating level. 

3.2.5 Preference 

25 This is a top-level interface 330 which is common 

for all preference/settings subinterf aces . It supports 
the listener model and provides the preference name. 
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This interface can be extended to support specific 
preferences with specific access methods. It is 
derived from Pref erenceNames 320. 

Public Operations : 
5 addPropertyChangeListener (aListener : 

PropertyChangeListener) : void 

This method allows applications interested in 
changes to this preference to register for preference 
change events. 
10 reitiovePropertyChangeListener (aListener ; 

PropertyChangeListener) : void 

This method allows a preference change listener to 
remove itself from the list of listeners. 

getPref erenceName () : String 

15 This method returns a unique preference name. 

3*2.6 Pref erenceNames 

This interface 320 contains a list of predefined 
preference names. 

Public Attributes : 
2 0 SIMPLE_RATING : String = "Simple Rating" 

LANGUAGE : String = "Language" 

3.2.7 Pref erenceRegistryEvent 

This event 360 informs the RegistryListener 440 
about changes in the Pref erenceRegistry 310. It is 
25 derived from RegistryChangeEvent 250. 

Public Operations: 

getPref erence () : org. atsc. preferences .Pref erence 

Returns the preference that has changed in the 
repository. This change concerns the repository, such 
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as adding or removing a Preference from* the 

Pref erenceRegistry 310, not a change in the value of 

the Preference. 

3.2.8 Pref erenceChangeCause 

This interface 345 defines reasons for a 
Pref erenceRegistryEvent 360. 
Public Attributes: 
PREFERENCE_ADDED : short = 1 
PREFERENCE_REMOVED : short = 2 

3.3 Registry Package 

This package 13.0 provides a set of supporting and 
utility classes and interfaces used by other packages. 

3.3.1 Registry 

This interface 410 provides a common root to all 
specialized registry interfaces, such 
ApplicationRegistry 490, ResourceRegistry 480, 
Pref erenceRegistry 310, etc. It is provided so that 
the RegistryFactory 430 can return a base type. 

A "base type" is known from the field of object- 
oriented programming. To illustrate, one can define a 
class with a set of functions (methods) and internal 
variables (e.g., a class "Fruit" which represents fruit 
and its' basic characteristics) . One can specialize it 
by defining a new class, "Apple", which inherits 
everything from the class "Fruit", and adds new 
functions that are applicable only to Apples but not to 
Fruit in general. "Fruit" is then referred to as a 
"base class" or a "base type." 
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The Registry interface 410 is derived from 
RegistryType 405. 

Public Operations : 
getRegistryType ( ) : String 

5 Called to determine the type of registry 

implemented by the object returned by the 
RegistryFatory 1 s (430) method getRegistry ( ) . 

addRegistryListener (listener: Registry-Listener ) : 

Called to register for events generated by the 
10 Registry 410 . 

removeRegistryListener (listener : 
Regis tryListener) : 

Called to de-register for events generated by the 
Registry 410. 

15 3 ,3 .2 Regis try Factory 

This class 430 provides a mechanism to create 
objects that implement specific Registry interfaces, 
such as the ApplicationRegistry 490. This class is 
modeled after the Factory Method design pattern, which, 
20 as is known from the field of object-oriented 

programming, is a methodology and structure for solving 
a problem. 

Public Operations : 

RegistryFactory ( ) : 

25 Constructor 

getRegistry ( regis tryName : String) : 
org . atsc . registry « Registry 

Returns an instance of an object which implements 
the specified registry interface. Returns null when 
30 specified registry does not exist or cannot be created. 
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The type of the returned object will be one of the 
derived Registry types, such as the ApplicationRegistry 
490 . 

3*3.3 RegistryType 

5 This interface 405 defines names for different 

registry types, such as an application registry, etc. 
Public Attributes: 

APPLICATION_REGISTRY ; String = "Application 
Registry" 

10 RESOURCE_REGISTRY : String = "Resource Registry" 

PREFERENCE_REGISTRY : String = "Preference 
Registry" 

USER_REGI STRY : String = "User Registry" 

3.3.4 RegistryListener 

This interface 440 allows an object to listen to 
changes made to the Registry 410. 
Public Operations: 

regis tryChange () ; ApplicationRegistryEvent 

This method of all registered 
ApplicationRegistryListeners is called by the 
ApplicationRegistry object 4 90 when an 
ApplicaionRegistryEvent is fired (emitted) . 

3.3.5 RegistryChangeEvent 

This event 250 is a generic registry change event 
25 that is extended by all specific registries (such as 

ApplicationRegistry 490, etc.) to provide specific 
information about the change. It is derived from 
Event Object 415. 



15 



20 



WO 00/30345 



PCT/US99/23346 



23 



Public Operations : 

getRegistryType () : j ava . lang . String 

Returns the type of a registry that this event is 
associated with. 
5 getCause () : short 

Returns the cause of the Regis tryChangeEvent 250. 
Each derived event will define a set of causes 
appropriate for the registry it represents. 

Accordingly, it can be seen that the present 

10 invention provides an API for applications to 

manage /access user-related information on a Digital 
Television (DTV) Receiver/Terminal. The API provides a 
multi-user environment, and a registry for preferences 
which can be associated with an individual user or be 

15 common to all users. A set of permissions is 

associated with each user, or at least with a default 
user. The permission may provide, for example, a 
parental control /rating ceiling or permission to buy 
Impulse Pay Per View (IPPV) programs, or engage in e- 

20 commerce transactions (e.g., purchase goods or services 

via the television) . The invention also supports a 
mechanism where some applications can, and some cannot, 
access the preferences based on a security policy. 
This means that the user may allow only specified 

25 trusted applications to access his/her credit card 

number- but not others, for example, for an e-commerce 
application. 

Although the invention has been described in 
connection with various specific embodiments, those 

3 0 skilled in the art will appreciate that numerous 
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adaptations and modifications may be made thereto 
without departing from the spirit and scope of the 
invention as set forth in the claims. 

For example, while various syntax elements have 
5 been discussed herein, note that they are examples 

only, and any syntax may be used. 

Moreover, the invention is suitable for use with 
virtually any type of network, including cable or 
satellite television broadband communication networks, 
10 local area networks (LANs) , metropolitan area networks 

(MANs) , wide area networks (WANs) , internets, 
intranets, and the Internet, or combinations thereof. 

Additionally, known computer hardware, firmware 
and/or software techniques may be used to implement the 
invention . 
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What is claimed is: 

1. A television set -top terminal, comprising: 

a computer readable medium having computer program 
code means ; and 

means for executing said computer program code 
means to implement an Application Programming Interface 
(API) for accessing user-related information at the 
terminal , wherein : 

the API provides: (a) a user registry of a 
plurality of users of the terminal, (b) a preferences 
registry of preferences of the users, and (c) 
permission (s) for controlling the users' access to at 
least one application that is provided at the terminal. 

2. The terminal of claim 1, wherein: 

the API provides a security policy to allow only 
specified applications to access the preferences 
registry . 

3. The terminal of claim 2, wherein: 
the security policy is user-controlled. 

4. The terminal of claim 1, wherein: 

the permission (s) are associated with each user. 

5. The terminal of claim 1, wherein: 

the permission (s) are associated with a default 

user . 



The terminal of claim 1, wherein: 
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the at least one application is responsive to the 
user preferences. 

7. The terminal of claim 1, wherein: 

the permission (s) control the users' access to a 
plurality of applications that are provided at the 
terminal . 

8. The terminal of claim 1, wherein: 

the preferences include a language preference. 

9. The terminal of claim 1, wherein: 
the preferences include a ratings ceiling 

preference . 

10. The terminal of claim 1, wherein: 
said user preferences include system-wide 

preferences. 

11. The terminal of claim 1, wherein: 
said user preferences include user-specific 

preferences . 

12. The terminal of claim 1, wherein: 

the user registry registers a new user of the 
terminal . 



13. The terminal of claim 1, wherein: 
the user registry identifies a current user of the 
terminal . 
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14. The terminal of claim 1, wherein: 

the user registry removes a former user of the 
terminal . 

15. The terminal of claim 1, wherein: 

the permission (s) enable the users to access a 
resource of the terminal . 

16. The terminal of claim 1, wherein: 

the API is adapted to define at least one new type 
of user preference, and add the new type of user 
preference to the preferences registry. 

17. The terminal of claim 16, wherein: 

the API is adapted to associate the new type of 
user preference with the users. 

18. The terminal of claim 1, wherein: 

the API disallows access to user preferences by an 
application that does not have the required 
permission (s) . 

19. A method for implementing a software 
architecture for a television set- top terminal, 
comprising the steps of: 

providing a computer readable medium having 
computer program code means / and 

executing said computer program code means to 
implement an Application Programming Interface (API) to 
provide : 

(a) a user registry of a plurality of users of the 



WO 00/30345 



28 



PCT/US99/23346 



terminal, (b) a preferences registry of preferences of 
the users, and (c) permission (s) for controlling the 
users' access to at least one application that is 
provided at the terminal . 

20. The method of claim 19, wherein: 

the API provides a security policy to allow only 

specified applications to access the preferences 

registry. 
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